QRZ! Ham Radio 4/QRZ Ham Radio Callsign Database - Volume 4.iso/digests/tcp/940004.txt

Internet Message Format | 1994-11-13 | 12KB

Date: Sat,  8 Jan 94 04:30:06 PST
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V94 #4
To: tcp-group-digest


TCP-Group Digest            Sat,  8 Jan 94       Volume 94 : Issue    4

Today's Topics:
          Extended KISS and SMACK specifications?  (6 msgs)
                               Farewell
                              SUBSCRIBE
                         What does this mean?

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Fri, 07 Jan 1994 11:13:25 -0500
From: "Louis A. Mamakos" <[e-mail]>
Subject: Extended KISS and SMACK specifications?
To: Lyndon Nerenberg <[e-mail]>

> Do you work for Sun? This sounds like their reasoning for turning off NFS
> UDP checksums: dump the error checking so we can make the benchmarks look
> better.

No, I don't for Sun, and I think that lack of UDP checksums on NFS RPCs
was a really silly thing to do.

The point I was trying to make is that the original intent of KISS was
a simple, easy to implement way to get a host that has no direct radio
interface to talk to a TNC.  Sure, adding checksums or CRCs to frames
is a good thing.. but ACKs that the frames has been transmitted?  What
next?

My point is that if a problem needs to be solved, perhaps taking a
step back and starting over would be better than trying to organically
grow and extend a protocol that was never really intended to be
whacked on like this.

An example of this in the Internet world is SLIP being replaced by PPP
for extended functions.

louie
wa3ymh

------------------------------

Date: Fri, 7 Jan 1994 09:56:55 -0800 (PST)
From: Lyndon Nerenberg <[e-mail]>
Subject: Extended KISS and SMACK specifications?
To: "Louis A. Mamakos" <[e-mail]>

On Fri, 7 Jan 1994, Louis A. Mamakos wrote:

> The point I was trying to make is that the original intent of KISS was
> a simple, easy to implement way to get a host that has no direct radio
> interface to talk to a TNC.  Sure, adding checksums or CRCs to frames
> is a good thing.. but ACKs that the frames has been transmitted?  What
> next?

And I agree with you in principle, however there are two blatently
obvious features that are missing from KISS: link layer data integrity
checks (aka checksums) and transmision notification (aka timer
callbacks). The latter is very important for those running on conjested
slow speed networks (HF and 1200 bps VHF). I feel that both are important
enough that they overshadow any religious arguments concerning the name
of the protocol.

--lyndon

------------------------------

Date: Fri, 07 Jan 1994 17:19:53 -0500
From: "Brandon S. Allbery" <[e-mail]>
Subject: Extended KISS and SMACK specifications?
To: [e-mail]

In your message of Fri, 07 Jan 1994 09:56:55 PST, you write:
+---------------
| On Fri, 7 Jan 1994, Louis A. Mamakos wrote:
| > The point I was trying to make is that the original intent of KISS was
| > a simple, easy to implement way to get a host that has no direct radio
| > interface to talk to a TNC.  Sure, adding checksums or CRCs to frames
| > is a good thing.. but ACKs that the frames has been transmitted?  What
| > next?
|
| And I agree with you in principle, however there are two blatently
| obvious features that are missing from KISS: link layer data integrity
| checks (aka checksums) and transmision notification (aka timer
| callbacks). The latter is very important for those running on conjested
+---------------

There is also the point that amateur TCP/IP has enough problems getting
established in existing packet communities without requiring special hardware
on top of it.  KISS and extended KISS are easy to add to existing TNCs, and
KISS is already present in many of them, so a packeteer can experiment with
TCP/IP without having to go buy a special comm card.  Make that a requirement
and you'll see fewer people willing to try out TCP/IP, and less interest in
TCP/IP in the packet community.

Before someone suggests that we run SLIP to a "SLIP TNC", remember that such a
TNC must be rather more intelligent than current TNCs, and have more memory:
it has to be a router, not merely a protocol converter.

++Brandon
--
Brandon S. Allbery       [e-mail]         [e-mail]
"MSDOS didn't get as bad as it is overnight -- it took over ten years
of careful development."  [e-mail]
Do not taunt Happy Fun Coder.    (seen on the Net...)

------------------------------

Date: Fri, 7 Jan 94 16:21 PST
From: [e-mail] (Bruce Perens)
Subject: Extended KISS and SMACK specifications?
To: "Louis A. Mamakos" <[e-mail]>

Louie,

Innocently I ask for a document and ignite some sort of policy discussion :-) .

It's a bit late to argue the merits of extending KISS now. The firmware
already exists in (probably) tens of thousands of TNCs, and NOS (at least
WAMPES) uses it. The people who wrote it were doubtless too busy writing
software and could not take the time to have an argument about it.

    Bruce

--
Bruce Perens AB6YM [e-mail] 510-215-3502

------------------------------

Date: Fri, 7 Jan 94 16:05 PST
From: [e-mail] (Bruce Perens)
Subject: Extended KISS and SMACK specifications?
To: [e-mail]

Running serial links without error control in a high-RF environment is
both Simple and Stupid. For me, it breaks above 4800 baud, probably
because the PK-88 starts dropping characters. If I enable KISS
checksums, the TNC does not transmit a garbage packet when errors
happen.

The only real way to keep it Simple without being Stupid is to junk the
TNC and use something like an SCC or PI card that obsoletes KISS.

Since nobody has been able to point out an extensions document.  I'm
going to use my AEA manual as a document for the extensions that aren't
in SMACK.

    Bruce Perens

--
Bruce Perens AB6YM [e-mail] 510-215-3502

------------------------------

Date: Fri, 7 Jan 94 16:40:28 PST
From: [e-mail] (Dana Myers )
Subject: Extended KISS and SMACK specifications?
To: [e-mail]

> Subject: Extended KISS and SMACK specifications?
> Date: Fri, 07 Jan 1994 17:19:53 -0500
> From: "Brandon S. Allbery" <[e-mail]>
>
> In your message of Fri, 07 Jan 1994 09:56:55 PST, you write:
> +---------------
> | On Fri, 7 Jan 1994, Louis A. Mamakos wrote:
> | > The point I was trying to make is that the original intent of KISS was
> | > a simple, easy to implement way to get a host that has no direct radio
> | > interface to talk to a TNC.  Sure, adding checksums or CRCs to frames
> | > is a good thing.. but ACKs that the frames has been transmitted?  What
> | > next?
> |
> | And I agree with you in principle, however there are two blatently
> | obvious features that are missing from KISS: link layer data integrity
> | checks (aka checksums) and transmision notification (aka timer
> | callbacks). The latter is very important for those running on conjested
> +---------------
>
> There is also the point that amateur TCP/IP has enough problems getting
> established in existing packet communities without requiring special hardware
> on top of it.  KISS and extended KISS are easy to add to existing TNCs, and
> KISS is already present in many of them, so a packeteer can experiment with
> TCP/IP without having to go buy a special comm card.  Make that a requirement
> and you'll see fewer people willing to try out TCP/IP, and less interest in
> TCP/IP in the packet community.
>
> Before someone suggests that we run SLIP to a "SLIP TNC", remember that such a
> TNC must be rather more intelligent than current TNCs, and have more memory:
> it has to be a router, not merely a protocol converter.
>
> ++Brandon


Well, Phil's original intent of KISS was to provide a bridge between current
TNCs and plug-in adapters which he appears to have expected to become more
prevalent by now.  Reading the paper in the CNC plainly indicates this.

However, history has not quite played out that Phil, and pretty much
everyone else, expected.  Plug-in packet interfaces are not the rage,
and KISS has taken on a life quite different than the limited one
Phil envisioned.  The KA9Q IP suite was the motivation for KISS, but
BBS software has embraced it, too, and the issues driving the extension
of KISS can not be dismissed.

Of course, Phil is far more capable of speaking for himself than I can
speak for him, but I tend to believe KISS has grown beyond what he
really expected.  Therefore, I'm not sure it makes sense, today, to
re-iterate the principles that drove the creation of KISS and prevent
improvement of the protocol....

------------------------------

Date: Fri, 7 Jan 94 17:17:49 MET
From: [e-mail]
Subject: Farewell
To: [e-mail]

Hello Folks,
Here is my letter of goodby,
As Control Data does not want to make use of my services (after being there
27 years) anymore , I do have to pull some plugs. One is the gateway.
Others are the mail lists I am on.  (this one).
How I can keep a link to ucsd.edu to send my domain updates is also an unknown.
Perhaps some other gateway i might reach from 44. net can be of use.
Thanks all for having a wonderfull time on the net (with net/nos).
73's and till we meet again. (i am hunting for another job....but being 46
doesn't help in the market.)
Regards, Gerard.
PS, I was thinking of a nice speech but.....
--
Internet: [e-mail]                  |     Gerard J van der Grinten
UUCP:     gvdgpc!gvdg                   |     Control Data Bv.
Telephone: 0([phone]             |     Olaf Palmestraat 20
                                        |     2616 LS DELFT    Netherlands

------------------------------

Date: Fri,  7 Jan 94 10:04:00 -0600
From: [e-mail] (Tim Havens)
Subject: SUBSCRIBE
To: [e-mail]

add telcom!wx2l![e-mail]

------------------------------

Date: Fri, 7 Jan 1994 18:57:25 -0800
From: [e-mail] (Phil Karn)
Subject: What does this mean?
To: [e-mail]

>    Is there a reason not to have it compiled in so it doesn't
>    waist bandwidth or something? It sure looks that way, also

Source quenches have long been controversial. One school thinks
they're a bad idea because they add load to the network just when you
can least afford it, and another thinks they can still be useful in
managing congestion, especially when the congestion is only occurring
at widely scattered spots. I tend to belong to the latter school.

Of course, unless the sender does something with a source quench, then
it really doesn't do anything at all. I have my TCP back its
congestion window down to 1 packet, just as if it had timed out and
retransmitted. This does throttle TCP down if there is real congestion.

In a couple of places where I send source quenches, host unreachables
are arguably more appropriate. An unresolved ARP state is one of them.
I don't send them, though, because many non-compliant TCPs out there
still abort their connections when they receive even a single unreachable.

Phil

------------------------------

End of TCP-Group Digest V94 #4
******************************